home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / documentos / wendigo.txt < prev   
Text File  |  1999-05-11  |  47KB  |  913 lines
  1.  
  2. ─ Los documentos de IBERHACK  ────────────────────────────────────────────────
  3. ────────────────────────── http://www.geocities.com/SiliconValley/Park/7574───
  4.  Fecha: 13 Sep 96          
  5.     De: Wendigo <SHE - Sindicato de Hackers Españoles ->                                                        
  6.   Para: Todos                                                                  
  7.   Tema: Introduccion al hacking.
  8. ──────────────────────────────────────────────────────────────────────────────
  9.  
  10.  
  11. Aqui os dejo las famosas Hack Intros de Wendigo!!!
  12.  
  13. --------------------------------Cut Here-------------------------------------
  14.  
  15. Bueno, pues eso, que como alguien me ha pedido que expliquemos un poco de
  16. qué va el hacking pues yo me lanzo. Voy a empezar a explicarlo a nivel MUY
  17. elemental y desde un punto de vista práctico, si alguien quiere más detalles
  18. teóricos que lo diga, el cliente siempre tiene la razón. :-))))))
  19.  
  20. Otra cosa, si alguien cree que este tipo de mensajes son un coñazo, que me
  21. lo diga sin rodeos. :-)
  22.  
  23. Muy bien, para empezar cuando se habla de hackear EN GENERAL se habla de
  24. hackear máquinas con sistema operativo Unix. Aparte del Unix también existen
  25. otros sistemas operativos para mainframes y miniordenadores como el VMS
  26. para ordenadores VAX (de la marca DEC --> Digital Equipment Corporation),
  27. el VM/CMS, VM/ESA, etc para ordenadores IBM, y otros sistemas operativos de
  28. menor profileración.
  29.  
  30. Incluso los sistemas Unix se pueden clasificar en varios tipos, como el BSD,
  31. el SYSTEM V y el POSIX, así como varios sistemas desarrollados por las
  32. diferentes compañías informáticas:
  33.  
  34. AIX --> Unix de IBM
  35. SunOS --> Unix de Sun
  36. Solaris --> Unix de Sun (más avanzado que el SunOS)
  37. HP-UX --> Unix de Hewlett Packard
  38. Ultrix --> Unix de DEC para plataformas VAX
  39. OSF/1 --> Unix de DEC para plataformas ALPHA
  40. ConvexOS --> Unix de Convex
  41. Unicos --> Unix de Cray
  42. Linux --> Sin comentarios. :-)
  43.  
  44. Esta subdivisión de los sistemas Unix tiene más importancia de la que parece
  45. a primera vista, porque un bug o fallo de seguridad que funcione en uno de
  46. los sistemas puede que no funcione en los demás, por lo que es importante
  47. saber en todo momento cual es el sistema en el que nos estamos moviendo.
  48.  
  49. De la misma forma, Internet no es la única red en la cual se puede hackear,
  50. también hay varias redes de X.25 que cuentan con gran número de ordenadores
  51. como Sprintnet (la antigua Telenet), Tymnet o la misma Iberpac.
  52.  
  53. Aquí cuando hablemos de hackear estaremos hablando de hackear sistemas Unix
  54. en Internet preferentemente, ya que Internet está basada en los protocolos
  55. TCP/IP los cuales están mejor estudiados en cuanto a seguridad y por tanto
  56. existen más fuentes de información de donde se pueden conocer sus fallos de
  57. seguridad de las que existen para las redes X.25.
  58.  
  59. A la hora de hackear un sistema se pueden distinguir varios pasos
  60. diferenciados.
  61.  
  62. 1 - Introducirse en el sistema que tengamos como objetivo.
  63.  
  64. 2 - Una vez conseguido el acceso, conseguir privilegios de root (administrador
  65.     del sistema).
  66.  
  67. 3 - Borrar nuestras huellas.
  68.  
  69. 4 - Poner un sniffer (programa que monitoriza la red consiguiendo logins y
  70.     passwords) para tener acceso a otros sistemas.
  71.  
  72. NOTA: Voy a hacer un pequeño resumen de cada paso, lo que voy a decir está
  73.       basado en la generalidad pero no hay que tomarlo como dogma.
  74.  
  75.  
  76.  
  77. PASO UNO: Introducirse en el sistema.
  78.  
  79. Los fallos de seguridad que se aprovechan para conseguir introducirse en el
  80. sistema están basados casi siempre en los protocolos TCP/IP, en servicios
  81. de red como el NFS o NIS o en los comandos "r" de Unix.
  82.  
  83. TCP/IP --> TCP = Transport Control Protocol
  84.            IP  = Internet Protocol
  85.  
  86.            Los protocolos basados en TCP/IP que se suelen aprovechar son
  87.            Telnet, FTP, TFTP, SMTP, HTTP, etc. Cada uno de ellos tiene sus
  88.            propios agujeros de seguridad que se van parcheando con nuevas
  89.            versiones de estos protocolos, pero siempre aparecen nuevos bugs.
  90.            Explicar cada uno de los protocolos TCP/IP puede llevarnos mucho
  91.            tiempo, así que paso a otra cosa.
  92.  
  93. Servicios de red --> NFS = Network File System, es un servicio de red por el
  94.                      cual varias máquinas llamadas clientes comparten uno o
  95.                      varios directorios que se encuentran fisicamente en una
  96.                      máquina llamada servidor. Una máquina cliente, a pesar
  97.                      de no poseer fisicamente dichos directorios, puede
  98.                      montarlos de tal forma que puede acceder a ellos como
  99.                      si los poseyera. Otra cosa muy distinta es lo que se
  100.                      pueda hacer con los ficheros incluidos en dichos
  101.                      directorios (si se pueden borrar, modificar, alterar los
  102.                      permisos, etc), lo cual depende de la configuración del
  103.                      NFS.
  104.                      En la mala configuración del NFS es donde estriban
  105.                      siempre sus fallos de seguridad.
  106.  
  107.                      NIS = Network Information Service, es un servicio
  108.                      por el cual varias máquinas comparten varios "mapas".
  109.                      Los mapas son ficheros como passwd, hosts, etc.
  110.                      Por ejemplo, un usuario puede entrar con la misma
  111.                      cuenta en todas las máquinas que compartan un mismo
  112.                      mapa de passwords. Los mapas son consultados por las
  113.                      máquinas clientes a las máquinas que contengan los
  114.                      mapas, que son los servidores.
  115.                      Existe un programa llamado YPX que sirve para extraer
  116.                      estos mapas (incluído el fichero passwd, donde están
  117.                      incluídas todas las passwords de los usuarios) de un
  118.                      servidor de NIS aunque la máquina en la que estemos no
  119.                      sea una máquina cliente.
  120.  
  121. Comandos "r" --> Son comandos exclusivos del sistema operativo Unix. La "r"
  122.                  es de remote. En el sistema hay un fichero llamado host.equiv
  123.                  y cada usuario suele tener en su directorio home (el
  124.                  directorio reservado a cada usuario para su propio uso
  125.                  del sistema) un fichero llamado .rhosts. Dependiendo de la
  126.                  configuración de estos dos ficheros se podrá o no acceder
  127.                  a dicho ordenador desde otro sistema unix sin necesidad de
  128.                  password con los comandos rlogin o rsh.
  129.  
  130. Aparte de estas formas básicas, existen otras formas más avanzadas de acceder
  131. a un sistema como el IP Spoofing, fallos de seguridad en el Web y el Java,
  132. recompilando librerías del telnet, UUCP, etc.
  133.  
  134. Hay dos formas básicas de introducirse en el sistema:
  135.  
  136. 1 - Entrar directamente sin necesidad de poseer una cuenta en el sistema
  137.     objetivo.
  138.     Por ejemplo por comandos "r" o por algún bug (alterar el fichero passwd
  139.     del ordenador objetivo por rsh, alterar el fichero .rhosts de algún
  140.     usuario por NFS, etc...desde luego hay formas más avanzadas de conseguir
  141.     esto).
  142.  
  143. 2 - Conseguir el fichero passwd del sistema objetivo y crackearlo.
  144.     El fichero passwd contiene los logins de los usuarios y su correspondiente
  145.     password encriptadas (entre otras cosas). Para averiguar el password de
  146.     cada usuario se utiliza un programa crackeador (existen varios, para
  147.     unix el más famoso es el Crack, para MS-DOS están el JackCrack, Hades,
  148.     Crack, etc) que encripta cada palabra de un diccionario y las compara
  149.     con la cadena encriptada del fichero passwd, cuando las cadenas
  150.     encriptadas coinciden entonces la palabra del diccionario que el programa
  151.     ha encriptado en ese momento es el password buscado.
  152.  
  153.  
  154.  PASO DOS: Conseguir privilegios de root una vez conseguido el acceso.
  155.  
  156.  En este caso, los fallos de seguridad que explotaremos serán los del
  157.  propio sistema operativo Unix, a diferencia de cuando teníamos que
  158.  introducirnos en el sistema, que explotábamos los agujeros de seguridad
  159.  de los protocolos o servicios de red.
  160.  
  161.  NOTA: De todas formas, hay que tener en cuenta que aunque explotemos los
  162.        bugs de los protocolos TCP/IP, esto no significa que estos bugs nos
  163.        vayan a funcionar con cualquier sistema operativo. Más bien al
  164.        contrario, estos bugs funcionan casi exclusivamente en el sistema
  165.        operativo Unix pero en otros sistemas operativos como VMS o VM no
  166.        funcionarán. Estos sistemas operativos tendrán sus propios bugs
  167.        respecto a los protocolos TCP/IP (de los cuales existe muy poca
  168.        información por no decir ninguna).
  169.  
  170.  Una vez introducidos en el sistema, habrá que conseguir dos cosas:
  171.  
  172.  1 - Conseguir privilegios de root.
  173.  
  174.      Esto se puede conseguir mediante varios bugs dependiendo del tipo de
  175.      unix en el que nos estemos moviendo (aix, sun, solaris, hp-ux, etc...)
  176.      y de cómo esté configurado dicho sistema.
  177.  
  178.      Existen varias fuentes de información en Internet para conocer bugs,
  179.      algunas de esas fuentes se limitan a indicar la existencia del bug
  180.      señalando el tipo de unix en el que funciona y otras incluso publican en
  181.      la red programas para explotarlos. Entre dichas fuentes de información
  182.      (mailing lists la mayoría) están el CERT, BUGTRAQ, BoS,
  183.      comp.security.unix, alt.2600 y un largo etc.
  184.  
  185.      En general los bugs se pueden clasificar en varias categorías, pero
  186.      eso en todo caso lo mencionaré más adelante, por ahora esto es un
  187.      pequeño resumen.
  188.  
  189.  2 - Mantener los privilegios de root.
  190.  
  191.      Existen diversas formas de mantener los privilegios de root, es decir,
  192.      asegurarnos de que la próxima vez que entremos al sistema con la cuenta
  193.      de un usuario que posea privilegios normales, podamos conseguir
  194.      privilegios de root de forma fácil y sin complicaciones.
  195.  
  196.      Quizá la forma más utilizada de conseguir esto sea el sushi (set-uid-
  197.      shell) o también llamado "huevo".
  198.      Consiste en que una vez alcanzados los privilegios de root, copiamos
  199.      un shell (el fichero /bin/sh) a un directorio público (en el que un
  200.      usuario normal pueda ejecutar los ficheros) y le cambiamos el nombre
  201.      al que nosotros queramos. Nos aseguramos de que el shell copiado tenga
  202.      como owner (propietario del fichero) al root y cambiamos los permisos
  203.      del fichero con las cifras 4755. Por ahora no os preocupeis de lo que
  204.      significan dichas cifras, pero la primera cifra, el 4, significa que
  205.      CUALQUIER usuario que ejecute dicho fichero lo estará ejecutando con
  206.      los privilegios del owner. Como en este caso el owner es el root y el
  207.      fichero en cuestión es una shell, el sistema nos abrirá un shell con
  208.      privilegios de root.
  209.  
  210.      De esta forma, la próxima vez que accedamos al sistema con la cuenta
  211.      de un usuario normal, sólo tendremos que cambiarnos al directorio donde
  212.      hayamos copiado el shell, ejecutarlo y ya seremos root sin las
  213.      complicaciones de tener que explotar un bug.
  214.  
  215.      Los sushis también tienen sus inconvenientes, ya que pueden ser
  216.      fácilmente localizados por los administradores (mediante el comando
  217.      find, por ejemplo) revelando nuestra presencia en el sistema. Para
  218.      evitar esto hay otras formas de mantener los privilegios en el
  219.      sistema o de modificar ligeramente los sushis para que no puedan ser
  220.      detectados tan fácilmente.
  221.  
  222.  
  223.  PASO TRES: Borrar nuestras huellas.
  224.  
  225.  Este paso es importante, ya que de nada nos habrá servido habernos
  226.  introducido en el sistema y haber conseguido el nivel de root si al día
  227.  siguiente nos han cortado el acceso debido a que hemos dejado huellas por
  228.  todas partes.
  229.  
  230.  El sistema operativo Unix guarda varios registros (logs) de las conexiones
  231.  de los usuarios al sistema. Existen varios ficheros y comandos que ayudan
  232.  al administrador a conocer todos los detalles acerca de las conexiones de
  233.  los usuarios. Aparte de estos ficheros y comandos, existen diversas
  234.  facilidades y aplicaciones que realizan un registro continuado y exhaustivo
  235.  acerca de las actividades del usuario dentro del sistema.
  236.  
  237.  Ficheros: (Cuando pongo dos directorios significa que el fichero puede estar
  238.            en cualquiera de esos dos directorios).
  239.  
  240.  utmp --> Guarda un registro (log) de los usuarios que están utilizando el
  241.           sistema mientras están conectados a él.
  242.  
  243.           Directorios: /var/adm/utmp
  244.                        /etc/utmp
  245.  
  246.  wtmp --> Guarda un log cada vez que un usuario se introduce en el sistema
  247.           o sale del sistema.
  248.  
  249.           Directorios: /var/adm/wtmp
  250.                        /etc/wtmp
  251.  
  252.  lastlog --> Guarda un log del momento exacto en que un usuario entró por
  253.              última vez.
  254.  
  255.              Directorio: /var/adm/lastlog
  256.  
  257.  acct --> Registra todos los comandos ejecutados por cada usuario (aunque no
  258.           registra los argumentos con que dichos comandos fueron ejecutados).
  259.  
  260.           Directorio: /var/adm/acct
  261.  
  262.           En algunos sistemas el fichero acct se puede llamar pacct
  263.  Comandos:
  264.  
  265.  who --> Permite saber quién está conectado al sistema en el momento en que
  266.          ejecutamos el comando.
  267.  
  268.  finger --> Lo mismo que el comando who, con el añadido de que se puede
  269.             aplicar a otras máquinas. Es decir, podemos saber qué usuarios
  270.             están conectados a una determinada máquina en el momento en que
  271.             ejecutamos el comando.
  272.  
  273.  users --> Igual que el who
  274.  
  275.  rusers --> Igual que finger, pero la máquina remota debe utilizar el sistema
  276.             operativo Unix.
  277.  
  278.  Los comandos who, finger, users y rusers toman la información que sacan en
  279.  pantalla del fichero utmp.
  280.  
  281.  last --> Permite saber cuando fué la última vez que se conectó un
  282.           usuario.
  283.  
  284.  El comando last toma la información que saca en pantalla del fichero wtmp.
  285.  
  286.  ps --> Permite saber qué procesos están siendo ejecutados por el sistema y
  287.         que usuarios los ejecutan.
  288.  
  289.  El comando ps ofrece una información mucho más completa de quién está
  290.  utilizando el sistema puesto que un usuario que no aparezca en los ficheros
  291.  utmp o wtmp puede tener procesos ejecutándose, por lo que el comando ps
  292.  ofrecerá la información de quién está ejecutando dichos procesos. En
  293.  contrapartida, la información que ofrece el comando ps es más complicada de
  294.  interpretar que la información ofrecida por el resto de comandos.
  295.  
  296.  accton --> Activa un proceso llamado accounting, que es el que proporciona
  297.             información al fichero acct.
  298.  
  299.  lastcomm --> Permite saber qué comandos han ejecutado los usuarios.
  300.  
  301.  acctcom --> Igual que lastcomm pero exclusivamente para Unix del tipo
  302.              SYSTEM V.
  303.  
  304.  Los comandos lastcomm y acctcom toman la información que sacan por pantalla
  305.  del fichero acct (pacct en algunos sistemas)
  306.  
  307.  Por lo tanto, si queremos borrar nuestras huellas del sistema, bastará con
  308.  borrar cualquier log relativo a nuestro usuario de los ficheros utmp, wtmp y
  309.  acct. Esto se puede hacer de dos formas:
  310.  
  311.  Ficheros utmp y wtmp:
  312.  
  313.  1 - No borramos los ficheros pero los dejamos con cero bytes. Sólo se
  314.      utiliza como último recurso por suscitar muchas sospechas por parte
  315.      de los administradores. Hay hackers que opinan que esto es incluso
  316.      peor que no borrar los logs.
  317.  
  318.  2 - Los ficheros utmp y wtmp no son ficheros de texto, es decir, no se
  319.      pueden editar con un editor de textos. Sin embargo, existen programas
  320.      llamados zappers (debido a que el programa más famoso de este tipo se
  321.      llama zap) que pueden borrar los datos relativos a un usuario en
  322.      particular de estos ficheros dejando el resto de los datos relativo a
  323.      los demás usuarios intacto.
  324.  
  325.  Fichero acct:
  326.  
  327.  Cuando el accounting está activado (es decir, cuando el sistema recoge
  328.  información acerca de los comandos ejecutados en el fichero acct) es
  329.  bastante complicado borrar nuestras huellas, de hecho no se pueden borrar
  330.  del todo, aunque sí se pueden reducir a una mínima información de nuestra
  331.  presencia en el sistema.
  332.  
  333.  1 - LO PRIMERO que hacemos nada más entrar en el sistema es copiar el
  334.      fichero acct a otro fichero y LO ULTIMO que hacemos antes de abandonar
  335.      el sistema es copiar dicho fichero de nuevo al acct, de modo que los
  336.      comandos que hemos ejecutado durante la sesión no aparecen en el
  337.      fichero acct.
  338.  
  339.      Problema: Nuestra entrada en el sistema queda registrada, así como las
  340.                dos copias.
  341.  
  342.  2 - Dejamos el fichero acct a cero bytes. Como antes, esto es bastante
  343.      sospechoso para un administrador, además, algunos sistemas reaccionan
  344.      mal y paran el proceso de accounting, para no levantar sospechas habría
  345.      que reactivarlo con el comando accton.
  346.  
  347.      Problema: Bastante sospechoso. El propio comando accton quedaría
  348.                registrado como ejecutado por nuestro usuario.
  349.  
  350.  3 - Hacerse un editor para el fichero acct que borrara los datos
  351.      correspondientes a nuestro usuario y dejara intactos los datos relativos
  352.      al resto de los usuarios. Existen unos pocos programas que hacen esto.
  353.  
  354.      Problema: La ejecución del programa editor que borra nuestras huellas
  355.                quedaría registrado como ejecutado por nuestro usuario.
  356.  
  357.  Afortunadamente, no hay muchos sistemas que tengan activado el accounting
  358.  debido a la cantidad de capacidad que es necesaria para guardar los
  359.  comandos ejecutados por cada usuario.
  360.  
  361.  
  362.  Aparte de los ficheros utmp, wtmp, acct y lastlog, hay que tener en cuenta
  363.  otras facilidades y aplicaciones que posee el sistema operativo Unix que
  364.  permiten al administrador vigilar ciertos aspectos críticos relativos a la
  365.  seguridad y al mantenimiento del sistema.
  366.  
  367.  1 - Syslog
  368.  
  369.      Syslog es una aplicación que viene con el sistema operativo Unix.
  370.      El sistema operativo Unix se puede configurar de tal forma que
  371.      determinados programas, procesos o aplicaciones generen mensajes que son
  372.      enviados a determinados ficheros donde quedan registrados dichos
  373.      mensajes. Estos mensajes son generados cuando se dan unas determinadas
  374.      condiciones, ya sean condiciones relativas a seguridad, mantenimiento
  375.      o simplemente de tipo puramente informativo.
  376.  
  377.      Para conseguir esto hay que configurar varias cosas.
  378.  
  379.      A - Decidir qué programas, procesos y aplicaciones pueden generar
  380.          mensajes. (Pongo los principales)
  381.  
  382.          kern --> mensajes relativos al kernel
  383.          user --> mensajes relativos a procesos ejecutados por usuarios
  384.                   normales.
  385.          mail --> mensajes relativos al sistema de correo.
  386.          lpr -->  mensajes relativos a impresoras.
  387.          auth --> mensajes relativos a programas y procesos de autentificación
  388.                   (aquellos en los que estén involucrados nombres de usuarios
  389.                   y passwords, por ejemplo login, su, getty, etc)
  390.          daemon --> mensajes relativos a otros demonios del sistema.
  391.  
  392.          etc...
  393.  
  394.      B - Decidir qué tipos de mensajes pueden generar cada uno de esos
  395.          programas, procesos o aplicaciones.
  396.  
  397.          emerg --> emergencias graves.
  398.          alert --> problemas que deben ser solucionados con urgencia.
  399.          crit --> errores críticos.
  400.          err --> errores ordinarios.
  401.          warning --> avisos.
  402.          notice --> cuando se da una condición que no constituye un error pero
  403.                     a la que se le debe dar una cierta atención.
  404.          info --> mensajes informativos.
  405.  
  406.          etc...
  407.  
  408.      C - Decidir a qué ficheros van a para dichos mensajes dependiendo del
  409.          tipo al que pertenezca el mensaje correspondiente.
  410.  
  411.  
  412.      Syslog cumple su función mediante el syslogd (syslog daemon o en
  413.      castellano el demonio syslog).
  414.  
  415.      NOTA: un demonio (o daemon) es un proceso que no tiene propietario (es
  416.            decir, no es ejecutado por ningún usuario en particular) y que
  417.            se está ejecutando permanentemente.
  418.  
  419.      El syslogd lee su configuración del fichero /etc/syslog.conf
  420.      Dicho fichero contiene la configuración relativa a qué eventos del
  421.      sistema son registrados y en qué ficheros son registrados. Los
  422.      ficheros a los cuales se mandan los registros (logs) pueden estar
  423.      situados en la misma máquina en la que estamos trabajando o en otra
  424.      máquina de la red.
  425.  
  426.  
  427.      Cómo borrar las huellas relativas al syslog:
  428.  
  429.      Bien, nuestras andanzas por el sistema cuando hemos accedido a él y
  430.      cuando nos hemos convertido en root, pueden generar diversos mensajes
  431.      registrados por el syslogd y guardados en los ficheros indicados en el
  432.      /etc/syslog.conf
  433.  
  434.      A diferencia de los ficheros utmp, wtmp, acct y lastlog, los ficheros
  435.      en los que se guardan los registros del syslog sí se pueden editar con
  436.      un editor de textos.
  437.  
  438.      Para poder borrar estas huellas necesitamos tener privilegios de root,
  439.      naturalmente. Bastará con examinar el fichero /etc/syslog.conf para
  440.      saber los ficheros que guardan los registros del syslog. Después
  441.      miraremos cada uno de esos ficheros comprobando que no hay ningún mensaje
  442.      relativo a nuestra intrusión en el sistema (los mensajes del estilo
  443.      "login: Root LOGIN REFUSED on ttya" a ciertas horas de la noche son
  444.      bastante sospechosos :-) ). En caso de que lo haya, lo borramos y
  445.      CAMBIAMOS LA FECHA del fichero con el comando touch de forma que
  446.      coincida la fecha del último mensaje (después de haber borrado nuestras
  447.      huellas) con la fecha del fichero. Si no lo hacemos así, algún
  448.      administrador demasiado suspicaz puede comprobar que las fechas no
  449.      coinciden y deducir que alguien ha modificado el fichero (esta es una
  450.      precaución extrema pero la recomiendo por experiencia). Si es necesario,
  451.      y SOLO si es necesario, habría que cambiar la fecha de los directorios
  452.      en los que estén incluídos los ficheros que guardan los logs.
  453.  
  454.      Si en el fichero /etc/syslog.conf hay mensajes que se destinan a
  455.      /dev/console eso significa que los mensajes (ya sean de error, alerta
  456.      o emergencia) salen directamente en la pantalla del root (o sea, en la
  457.      consola). En este caso no se puede hacer nada (que yo sepa), pero
  458.      mensajes de este tipo suelen estar generados por alertas bastante
  459.      graves como por ejemplo intentar acceder con la cuenta de root
  460.      directamente o utilizar el comando su para intentar convertirse en root,
  461.      etc. Es decir, cuanto más sigilosos seamos a la hora de hacernos root
  462.      y menos ruido armemos más posibilidades tendremos de no aparecer en este
  463.      tipo de logs.
  464.  
  465.  2 - TCP-Wrapper
  466.  
  467.      Se trata de una aplicación que proporciona una serie de mecanismos
  468.      para el registro (logging) y filtro (filtering) de aquellos servicios
  469.      invocados o llamados a través del inetd (internet daemon). Con esta
  470.      herramienta el administrador posee un control absoluto de las
  471.      conexiones hacia y desde su máquina.
  472.  
  473.      Puede, entre otras muchas cosas, filtrar un servicio de internet como
  474.      por ejemplo el telnet, ftp, etc de forma que nadie pueda conectarse
  475.      al sistema desde otra máquina o puede especificar una lista de máquinas
  476.      que sí pueden conectarse (y las demás no podrán). Además, el
  477.      administrador es informado en todo momento y con todo lujo de detalles
  478.      de las conexiones que se han hecho desde su máquina y hacia su máquina
  479.      con cualquiera de los diferentes servicios de internet (telnet, ftp,
  480.      finger, etc...)
  481.  
  482.      Como en el syslog, para borrar nuestras huellas del tcp-wrapper, tendremos
  483.      que buscar posibles huellas mirando el archivo de configuración (alojado
  484.      NORMALMENTE en el directorio /etc), borrar dichas huellas y cambiar las
  485.      fechas de los ficheros correspondientes.
  486.  
  487.  Bien, hasta aquí un resumen sobre cómo borrar las huellas. Como vereis me
  488.  he extendido un poco más porque me parece importante que la gente adquiera
  489.  conciencia de que tan importante o más que controlar el sistema (convertirse
  490.  en root) es saber ocultarse en él (aunque es una opinión personal).
  491.  
  492.  Puede parecer bastante pesado el borrar todas las posibles huellas que
  493.  hayamos dejado, pero en ALGUNAS ocasiones, una vez que hayamos visto los
  494.  ficheros de configuración es posible preparar un shell script (el equivalente
  495.  a los ficheros batch en MS-DOS, aunque la programación en shell es
  496.  infinitamente más potente :-) ) que haga todo el trabajo por nosotros en
  497.  cuestión de borrar las huellas. Dicho script lo podemos dejar bien camuflado
  498.  en el sistema para que la próxima vez que entremos lo podamos ejecutar
  499.  (utilizando como parámetros el usuario con el que hayamos entrado, el
  500.  terminal por el que hayamos entrado, la hora a la que hayamos entrado, etc..)
  501.  ahorrándonos todo el trabajo pesado.
  502.  
  503.  Para terminar con lo de borrar las huellas, sólo advertir que aunque seamos
  504.  perfectamente invisibles en el sistema, cualquier usuario que esté conectado
  505.  al mismo tiempo que nosotros podría detectarnos viendo el terminal por el
  506.  que hemos entrado (el fichero /dev/ correspondiente a nuestro terminal
  507.  tendría como propietario (owner) al usuario con el que hemos entrado en el
  508.  sistema, y la fecha del fichero /dev/ correspondiente al terminal también
  509.  nos delataría). Para evitar esto tendríamos que cambiar de owner el fichero
  510.  correspondiente al terminal (teniendo privilegios de root naturalmente)
  511.  al owner que tengan los otros terminales a los cuales no hay nadie
  512.  conectado (es decir, al owner de los terminales por defecto que NORMALMENTE
  513.  es el root).
  514.  
  515.  De todas formas, esto último, junto con lo de cambiar de fecha ciertos
  516.  ficheros de logs, son medidas quizá extremas, pero vuelvo a insistir que
  517.  son muy recomendables.
  518.  
  519.  Por último, la cuestión de ocultar o camuflar procesos mientras los estamos
  520.  ejecutando es otra cuestión que se tratará en otro mensaje si teneis la
  521.  paciencia de seguir. :-)
  522.  
  523.  
  524.  Ya hemos visto de forma resumida y sin detallar algunas técnicas sobre cómo
  525.  conseguir acceso, conseguir privilegios y borrar nuestras huellas. Vamos a
  526.  ver el último paso, cómo conseguir acceso a otros ordenadores una vez
  527.  controlado el host que hayamos hackeado (es decir, después de asegurarnos
  528.  que hemos borrado absolutamente todas nuestras huellas y de implantar
  529.  algún sushi u otro método análogo para conseguir privilegios de root).
  530.  
  531.  Una vez controlado el host que teníamos como objetivo, podemos hacer todo
  532.  lo que queramos en el sistema, aunque hay que tener en cuenta que nuestras
  533.  acciones pueden ser registradas por el syslog, tcp-wrapper u otra utilidad
  534.  que genere logs, por lo que cuando vayamos a irnos del sistema siempre
  535.  tendremos que comprobar antes que no hemos dejado registros (logs).
  536.  
  537.  Es en este punto donde adquiere importancia la "filosofía" del hacker. La
  538.  diferencia entre un hacker y un cracker (no me estoy refiriendo a alguien
  539.  que rompe las protecciones de software), consiste en que un cracker accede al
  540.  sistema para dañarlo o corromperlo y un hacker accede al sistema simplemente
  541.  para conseguir información o por pura curiosidad, pero nunca corromperá ni
  542.  borrará ningún fichero del sistema, sigue el lema (aunque tampoco de forma
  543.  radical, es decir, sin tomárselo al pie de la letra) de "se ve pero no se
  544.  toca". A esto último hay que hacer una excepción , naturalmente. Los únicos
  545.  ficheros que el hacker modificará o borrará serán los ficheros relativos a
  546.  los logs que haya podido dejar en el sistema. Por supuesto que esto es una
  547.  situación ideal y no realista, en la práctica un hacker puede que realize
  548.  otras acciones en el sistema que puedan modificar ficheros ya existentes,
  549.  pero siempre procurará que los cambios sean mínimos.
  550.  
  551.  
  552.  PASO CUATRO:
  553.  
  554.  Bien, para conseguir acceso a otros sistemas desde el host que hemos hackeado
  555.  existen varias técnicas. La más sencilla y la primera que se suele probar es
  556.  consultando los ficheros .rhosts de los usuarios e intentando acceder a los
  557.  sistemas incluídos en dichos ficheros mediante rlogin o rsh. También se
  558.  puede intentar acceder a otros sistemas de la red con los comandos "r"
  559.  aunque no estén incluídos en los ficheros .rhosts o en el fichero host.equiv.
  560.  
  561.  Hay varias formas más o menos sofisticadas que nos permitan conseguir
  562.  información desde el sistema en el que nos encontramos y que nos permita
  563.  acceder a otros sistemas de la red. Quizá el método más famoso y más
  564.  eficiente sea la colocación de un sniffer.
  565.  Un sniffer es un programa que "monitoriza" la red consultando los diferentes
  566.  paquetes de información que circulan por ella. Cuando alguno de esos paquetes
  567.  cumple ciertos requisitos (por ejemplo que sea un paquete correspondiente a
  568.  un proceso de login), guarda dicho paquete en un fichero (es decir, guarda
  569.  un log). Cada cierto tiempo el hacker puede consultar dicho fichero que le
  570.  proporciona información sobre qué usuario se conectó a una determinada
  571.  máquina, a qué máquina se conectó y que password utilizó, además de otros
  572.  datos.
  573.  
  574.  Cómo funciona un sniffer:
  575.  
  576.  La red Internet es un conjunto de subredes comunicadas entre sí mediante
  577.  máquinas llamadas gateways, bridges o routers. Cada subred, a su vez, puede
  578.  estar dividida en varias subredes y sucesivamente. Lo más usual es que las
  579.  máquinas estén organizadas en una red de tipo ethernet, y que dicha red esté
  580.  conectada a Internet (o a una subred de Internet) mediante sus
  581.  corrrespondientes routers o gateways (no tiene porqué ser sólo un router
  582.  o gateway, una misma red puede tener varios para comunicarse con el
  583.  exterior), que serán las máquinas que mantengan a dicha red ethernet en
  584.  contacto con el resto de la red.
  585.  
  586.  Las redes ethernet trabajan mandando los paquetes de información por un
  587.  mismo canal compartido por todas las máquinas. En la cabecera de cada
  588.  paquete de información está incluída la dirección de la máquina a la cual va
  589.  destinado el paquete de información. Se supone que el paquete de información
  590.  sólo lo recibe la máquina a la cual va destinado. Las máquinas que reciben
  591.  cualquier paquete de información aunque no estén destinados a ella, se dice
  592.  que están en modo promiscuo.
  593.  
  594.  De esta forma, un hacker puede poner en modo promiscuo la máquina (si es que
  595.  no lo está ya en el momento de hackearla) y capturar TODOS los paquetes que
  596.  circulan por la red, aunque no provengan de su máquina y aunque no estén
  597.  destinados a su máquina. Normalmente se suelen capturar paquetes que cumplan
  598.  algún requisito como aquellos que incluyan el momento de acceso de un usuario
  599.  a una máquina. Teniendo en cuenta que el login y el password del usuario se
  600.  mandan en modo texto, el hacker puede leer con toda comodidad en el fichero
  601.  registro que genera el sniffer qué password utiliza el usuario y en qué
  602.  máquina lo utiliza.
  603.  
  604.  También se puede sniffar información aunque el sistema no esté en modo
  605.  promiscuo, pero entonces la máquina sólo aceptará información que esté
  606.  destinada a ella, y los únicos paquetes de información que monitorizará el
  607.  sistema serán los paquetes destinados a él, y los paquetes que provengan del
  608.  propio sistema.
  609.  
  610.  Existen varios programas sniffers por la red, incluso algunos comerciales.
  611.  Los más conocidos y distribuidos en circulos underground son sniffers para
  612.  SunOS, Solaris y Linux. Por otra parte, programas bien conocidos como
  613.  Etherfind o Tcpdump se pueden utilizar estupendamente como sniffers, aunque
  614.  no hayan sido concebidos para esos fines.
  615.  
  616.  Para comprobar si un sistema está en modo promiscuo se utiliza el comando
  617.  ifconfig -a, aunque en algunos sistemas como el OSF/1 o el IRIX (el Unix
  618.  de Silicon Graphics) hay que especificar el interface (dispositivo mediante
  619.  el cual el sistema intercambia información con la red ethernet). Para
  620.  ver los interfaces se puede utilizar el comando netstat -r.
  621.  
  622.  Para terminar, sólo advertir que los logs, es decir, los ficheros que utiliza
  623.  el sniffer para guardar la información, suelen crecer muy deprisa por lo que
  624.  si no se tiene cuidado pueden hacerse excesivamente granden y alertar al
  625.  administrador del sistema que al examinar los ficheros se dará cuenta de que
  626.  existe un hacker en su sistema. Por eso es recomendable consultar los logs
  627.  cada POCO tiempo y dejar los ficheros a cero.
  628.  
  629.  
  630. Bien, ante todo quiero advertir que el tema que voy a tratar a continuación 
  631. está tratado desde un punto de vista personal. En hacking, como en casi
  632. cualquier actividad, cada maestrillo tiene su librillo. Sólo pretendo dar 
  633. unos consejos prácticos y desde luego NO recomiendo que se sigan al pie de
  634. la letra. Cada uno puede tener en cuenta estos consejos como base pero lo 
  635. mejor es que cada uno desarrolle su propio método y su propia forma de hacer
  636. las cosas.
  637.  
  638. Puede que muchos hackers (la gran mayoría mucho mejores que yo) que lean esto
  639. no estén de acuerdo con estos consejos o incluso los consideren nocivos para
  640. la práctica del hacking. Sólo puedo repetir que se trata de MI punto de vista
  641. y de MI opinión, y repetir que nadie se tome estas técnicas como dogma, sino
  642. que cada uno las ponga en práctica y después juzgue por sí mismo si vale la
  643. pena utilizarlas o no.
  644.  
  645.  
  646. RECOPILACION DE INFORMACION:
  647.  
  648. Bien, antes de intentar lanzarnos a hackear algún ordenador de la red conviene
  649. hacer algunos preparativos. Estos preparativos a los que me refiero constan 
  650. simplemente de una pequeña recopilación de información, tanto información
  651. general como información del ordenador que nos hayamos marcado como objetivo.
  652.  
  653.  
  654. 1 - Información general:
  655.  
  656.     Cuando menciono información general me estoy refiriendo a la recopilación
  657.     de bugs y programas que nos ayuden a hackear.
  658.  
  659.     Los bugs o fallos de seguridad y los programas que nos ayudan a 
  660.     explotarlos (aprovechar dichos fallos de seguridad) pueden conseguirse 
  661.     de varias formas:
  662.  
  663.              I - Mailing-lists de Internet:
  664.                  
  665.                      BoS --> Best of Security
  666.                      Bugtraq
  667.                      Comp.Security.Unix
  668.                      Alt.2600
  669.                      Linux.Security.Alert
  670.  
  671.                      etc.....
  672.  
  673.  
  674.              II - FTPs o WEBs "oficiales":
  675.  
  676.                      El más famoso es ftp.cert.org, pero existen una infinidad
  677.                      de ellos, basta con buscar mediante cualquier Search 
  678.                      Engine del WWW cualquier materia relacionada con la 
  679.                      seguridad.
  680.  
  681.     En los mensajes del CERT o de las distintas listas de correo los bugs no
  682.     se describen de manera directa. Es decir, no os dirán los pasos que teneis 
  683.     que dar para aprovechar los fallos de seguridad, sino que lo único que 
  684.     mencionarán será el sistema operativo al cual afecta el bug (SunOS, AIX,
  685.     Solaris, HP-UX, Ultrix, OSF/1, Irix, etc...), cual es el resultado de
  686.     aprovechar el bug (convertirse en root, poner los permisos que queramos
  687.     a un determinado fichero, estrellar el ordenador....) y los parches que
  688.     hay que aplicar al sistema para que dicho bug no pueda ser aprovechado en 
  689.     el futuro.
  690.  
  691.     Existen unas cuantas excepciones, los llamados EXPLOITS. Son mensajes
  692.     "oficiales" que muestran los pasos que hay que dar para aprovechar un 
  693.     determinado fallo de seguridad, e incluyen los programas necesarios
  694.     para hacerlo.
  695.     
  696.              III - FTPs, FSPs o WEBs "no oficiales":
  697.              
  698.                      Hay varios repartidos por Internet. Descubrirlos forma
  699.                      parte de las labores del hacker. En los que son 
  700.                      demasiado conocidos habrá cosas muy antiguas o que ya no
  701.                      funcionan.
  702.  
  703.                      Es en estos sites (se llama site o host a un ordenador 
  704.                      cualquiera de Internet) donde se consiguen las mejores
  705.                      utilidades y programas que nos permitan explotar varios
  706.                      bugs así como varias técnicas básicas de hacking.
  707.                      
  708.     Un buen hacker debe ser organizado. Organizar los bugs según un cierto
  709.     criterio es fundamental a la hora de hackear un ordenador. He visto 
  710.     gente que clasifica los bugs en distintos directorios según varios
  711.     criterios. Algunos los clasifican según la fecha. Es decir, almacenan en
  712.     un directorio los del 93, en otro los bugs aparecidos en el 94, en otro
  713.     los del 95, etc. Otras personas, entre las que me incluyo, los organizan
  714.     en distintos directorios según los sistemas operativos a los que afecten
  715.     o los protocolos de Internet a los que afecten. Es decir, yo tengo 
  716.     recopilados en un directorio todos los bugs que funcionan en SunOS (todos 
  717.     los que tengo yo, se entiende, no todos los que existen :-) ), en otro 
  718.     todos los que funcionan en Solaris, en otro los que funcionan en HP-UX, 
  719.     en otro los que se aprovechan fallos del sendmail, en otro los bugs
  720.     generales que puedan funcionar en varios sistemas, en otro directorio
  721.     los programas que me permitan borrar mis huellas, etc.
  722.  
  723.     A la hora de hackear un ordenador lo primero será averiguar el sistema
  724.     operativo que utiliza, su versión de sendmail, y otras cosas que explicaré
  725.     después. El tener organizados los bugs o los EXPLOITS así como otros 
  726.     programas de utilidad (zappers para borrar las huellas o sniffers para
  727.     conseguir cuentas) en directorios bien diferenciados nos permitirá ahorrar
  728.     mucho tiempo a la hora de hackear y lo más importante (lo digo por
  729.     experiencia), nos evitará hacernos lios y nos ayudará a decidirnos sobre
  730.     qué bugs intentar explotar en dicho sistema. 
  731.     
  732.  
  733.              IV - Zines o revistas electrónicas:
  734.  
  735.                   Las revistas o documentos electrónicos son llamados
  736.                   zines. En algunas de estas revistas o documentos están
  737.                   explicadas varias técnicas básicas de hacking así como
  738.                   lecciones de Unix orientadas a los hackers. Hay muchas
  739.                   revistas de este estilo y muy buenas:
  740.  
  741.                        FAQ de 2600
  742.                        Phrack
  743.                        LOD Technical Journal
  744.                        Cotno
  745.                        Infohax
  746.  
  747.                        etc....
  748.  
  749. 2 - Información del ordenador objetivo:
  750.  
  751.     Antes de intentar hackear un ordenador normalmente se recopilan una
  752.     serie de datos que nos ayuden a decidirnos sobre qué técnica de hacking
  753.     podemos utilizar.
  754.  
  755.     Se puede conseguir información muy variada de un determinado host 
  756.     (ordenador), pero quizá lo fundamental sea intentar hallar los 
  757.     siguientes datos:
  758.  
  759.     - Su dirección IP y su dirección de dominio.
  760.  
  761.       Cómo se consigue --> Si tenemos el host marcado como objetivo se 
  762.                            suponen conocidas. Si sólo conocemos la dirección
  763.                            de dominio para hallar la dirección IP basta
  764.                            utilizar el comando "nslookup <dirección.dominio>"
  765.  
  766.     - Tipo de sistema operativo Unix que utiliza  -->**MUY IMPORTANTE**<--
  767.  
  768.       Cómo se consigue --> Haciendo telnet <host>
  769.  
  770.     - Versión de Sendmail que utiliza 
  771.  
  772.       Cómo se consigue --> Haciendo telnet <host> 25
  773.                            Es decir, hacemos un telnet a la máquina pero al
  774.                            puerto 25. Una vez conectados para salir basta  
  775.                            utilizar QUIT o para obtener ayuda HELP.
  776.                     
  777.     - Si soporta RPC y en caso afirmativo averiguar qué servicios RPC tiene.
  778.     
  779.       Cómo se consigue --> Utilizando el comando "rpcinfo -p <host>"
  780.  
  781.     - Si exporta directorios. Es decir, si tiene NFS, y en caso afirmativo,
  782.       averiguar qué directorios exporta y a quién los exporta. 
  783.       
  784.       Cómo se consigue --> Utilizando el comando "showmount -e <host>"
  785.  
  786.     - Averiguar qué otras máquinas hay en ese mismo dominio, y que sistema 
  787.       operativo utilizan esas otras máquinas.
  788.  
  789.       Cómo se consigue --> Utilizando el comando "nslookup". Cuando salga el
  790.                            prompt del nslookup (un símbolo > ) se utiliza
  791.                            el comando "ls -d <dominio>" para obtener 
  792.                            información del dominio.
  793.                            
  794.     Con estos datos ya podemos intentar algunas técnicas de hacking, en las 
  795.     cuales profundizaremos en próximos mensajes. :-)
  796.  
  797. Por último algunos consejos importantes (repito: son consejos basados
  798. en mi experiencia, que cada uno desarrolle sus propios recursos):
  799.  
  800. 1 - En el caso de que consigais alguna cuenta para acceder al ordenador quizá
  801.     una vez hayais entrado no sepais muy bien cómo reaccionar, es decir, no
  802.     sepais qué hacer a continuación. Es en este momento donde toma importancia
  803.     la organización que mencioné antes. 
  804.  
  805.     En ningún momento os pongais nerviosos o intenteis cosas a loco. Si veis
  806.     que perdeis la calma lo mejor es apartarse de la pantalla diez o quince
  807.     minutos, relajarse, y después intentar hallar un camino para conseguir
  808.     privilegios.
  809.  
  810.     Para intentar conseguir privilegios de root es fundamental ante todo que
  811.     hagais una distinción de los bugs que podeis intentar explotar y aquellos
  812.     que no debeis intentar explotar (debido a que si son bugs de otro sistema
  813.     operativo Unix distinto al que estamos hackeando no servirán de nada),
  814.     por eso os aconsejé la distribución en directorios de los bugs según el
  815.     sistema o protocolo al que afecten. Esa organización os evitará pérdidas
  816.     de tiempo (con lo que aumenta la impaciencia del hacker :-) ) y os
  817.     ayudará a decidir las técnicas de hacking que debeis intentar de las que
  818.     no debeis intentar.
  819.  
  820.     A la hora de intentar explotar algún bug relativo al sistema que estemos
  821.     hackeando también es importante tener los exploits bien organizados y
  822.     convenientemente editados (muchas veces los exploits vienen mezclados 
  823.     en mensajes de texto) para que lo único que tengamos que hacer sea 
  824.     subirlos por FTP al sistema y ejecutarlos (y compilarlos si no fueran 
  825.     shell scripts).
  826.  
  827. 2 - En caso de que no os funcione ningún bug en el sistema de los que teneis,
  828.     ante todo mucha calma. :-)
  829.  
  830.     Importante: En este caso lo que debemos buscar es dejar las menos huellas
  831.                 posibles en el sistema. Las huellas que habeis dejado hasta 
  832.                 el momento no podreis borrarlas así que por mucho que os 
  833.                 preocupeis por ellas no podreis hacer nada, sólo esperar que
  834.                 el administrador no se dé cuenta de vuestras intrusiones
  835.                 (tanto en el utmp, wtmp o los logs del syslog). No intenteis
  836.                 cosas a lo loco como explotar bugs que funcionan en otros
  837.                 sistemas porque lo único que conseguireis será dejar más
  838.                 huellas y perder el tiempo.
  839.  
  840.     Lo que sí podeis hacer es intentar explotar bugs que afecten a los 
  841.     sistemas Unix en general (hay algunos) o bugs que afecten a alguno de
  842.     los protocolos TCP/IP. Si siguen sin funcionar ninguno dedicaos a 
  843.     explorar el sistema (hasta donde os permitan vuestros privilegios)
  844.     para tener una visión general de cómo está protegido el sistema (por
  845.     ejemplo viendo si los usuarios tienen ficheros .rhosts, si determinados
  846.     ficheros tienen permisos set-uid, que propietario tienen determinados
  847.     ficheros, etc...), y a partir de ahí teneis dos opciones PRINCIPALES (es
  848.     decir, que puede haber más opciones pero yo siempre utilizo una de estas 
  849.     dos):
  850.  
  851.      I - Olvidarse durante un par de días del sistema que intentamos hackear
  852.          y aprender todo lo que podamos sobre el sistema operativo Unix que 
  853.          utiliza esa máquina, ya sea buscando bugs más modernos que sirvan 
  854.          para la versión del sistema que intentamos hackear como examinando 
  855.          FAQs, documentos o páginas html que traten sobre dicho sistema en
  856.          general y su seguridad en particular, etc...
  857.  
  858.      II - Hackear otra máquina del mismo dominio y que sea más fácil de 
  859.           hackear, es decir, que sea mucho más insegura (hay sistemas más
  860.           "fáciles" o "inseguros" que otros debido a que se conocen más bugs
  861.           sobre ellos. Seguramente el SunOS 4.1.x sea el sistema del que se
  862.           conocen más bugs). Este método suele ser el más utilizado cuando
  863.           una máquina se nos resiste debido a que existen más recursos
  864.           al hackear una máquina (con técnicas que permiten conseguir
  865.           privilegios de root A LA VEZ que conseguimos entrar en dicha
  866.           máquina) desde una máquina de su mismo dominio que desde una máquina
  867.           que no pertenezca a su dominio.
  868.  
  869. 3 - Cuando no conseguimos acceder a un ordenador que pretendemos hackear el  
  870.     recurso que más se suele utilizar es el que hemos comentado antes. Se 
  871.     trata de hackear otra máquina del mismo domino que sea más insegura y
  872.     desde esa máquina hackear la máquina que nos hemos puesto por objetivo.
  873.  
  874.       I - La forma más sencilla es poner un sniffer en la máquina insegura
  875.           que hemos hackeado esperando conseguir una cuenta de la máquina
  876.           objetivo que pretendemos hackear. 
  877.  
  878.       II - Como he dicho antes, existen muchos más recursos para hackear una
  879.            máquina desde otra máquina de su mismo dominio de los que se pueden
  880.            utilizar al tratar de hackearla desde una máquina que no es de su
  881.            dominio. Por ejemplo aprovechando los ficheros .rhosts mediante 
  882.            los comandos rlogin o rsh, comprobando si la máquina objetivo
  883.            exporta directorios a la máquina que hemos hackeado, etc...
  884.  
  885. Para terminar un par de consejos para determinadas situaciones que se aprende
  886. a resolverlas a base de práctica, práctica y más práctica. Podeis leer un
  887. montón de documentos sobre hacking como este pero si quereis aprender a 
  888. hackear de verdad lo mejor es la práctica y ponerse manos a la obra cuanto
  889. antes, y que vosotros seais vuestros propios profesores.
  890.  
  891. 4 - Nunca os de miedo de intentar hacer cosas dentro del sistema (mientras
  892.     tengan algún sentido claro, como he dicho antes, no hay que hacer las
  893.     cosas a lo loco). No penseis que os van a pillar y que os van a cerrar el
  894.     acceso. Si os pillan y os cierran el acceso mala suerte, eso forma parte
  895.     del aprendizaje del hacker, os vais a hackear otro sistema y se acabó 
  896.     (incluso puede ser otro sistema del mismo dominio), pero siempre teneis
  897.     que experimentar, intentar las cosas por vosotros mismos, no os limiteis
  898.     a leerlas en un papel. Os descubrirán muchas veces y os cerrarán el acceso
  899.     otras tantas veces, pero cada vez ireis espabilando y lo ireis haciendo
  900.     mejor. Errores que cometisteis una o dos veces, más adelante no los
  901.     volvereis a cometer. En definitiva: aunque os dé angustia el que os 
  902.     cierren el acceso a algún ordenador al que ya habiais conseguido entrar,
  903.     no os dé miedo explorar el sistema y experimentar.
  904.  
  905. 5 - Muchas veces intentareis compilar un programa para explotar algún bug y 
  906.     os dará errores cuando se supone que debía compilar correctamente. 
  907.     Debuggar los programas también forma parte de las labores del hacker. 
  908.     Con la práctica aprendereis a reconocer porqué tal o cual código fuente 
  909.     no compila correctamente.
  910.  
  911.  
  912. --------------------------------Cut Here-------------------------------------
  913.